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Description 

[0001] The present invention relates to the certification 
of data sent over a network, more specifically over an 
insecure network such as the Internet by cryptographic 
means. 

[0002] Whenever information is transmitted across an 
insecure network, there is the possibility that this may be 
intercepted and interfered with in some way. Therefore, 
many activities carried out using such a network to con- 
nect the parties involved in the activity require each party 
to confirm the identity of the other party(s). This is par- 
ticularly the case with activities conducted over the Inter- 
net. 

[0003] One way of meeting the above requirement is 
to use a digital signature. The origin of data sent across 
an insecure network can be authenticated using such a 
digital signature. 

[0004] Such a signature fulfils the roles of a traditional 
signature: to provide authentication of origin, and may 
also have legal significance. It is therefore important to 
ensure that it is difficult, if not impossible, to sign an elec- 
tronic document fraudulently, in order to suggest an in- 
correct point of origin. 

[0005] A generally accepted - and the only known - 
way of achieving this is to use cryptography. In particular, 
a form of asymmetric cryptography called a public key 
scheme is used. A public key scheme employs two dif- 
ferent but mathematically related "keys". Such asymmet- 
ric keys work by using a so-called "one way" algorithm. 
Such an algorithm can be used to produce a so-called 
digital signature with one key and verify this with the other 
key, but it is very time-consuming and in fact practically 
infeasible, with the right choice of key size, to use the 
verifying key to generate the signature. Currently it is a 
very simple matter to use the verification key to verify the 
signature and hence the integrity and origin of the mes- 
sage, and this is how each key pair is normally used. 
These public key schemes may either be based on so 
called one-way functions, where the verification process 
involves checking a mathematical equation (e.g. EIGa- 
mal, elliptic curves, etc. see Menezes, A., Oorschot, 
P.van, and Vanstone, S., Handbook of Applied Cryptog- 
raphy, CRC, 1 996 or on encryption -decryption functions 
(e.g. RSA, see Rivest, R.L., Shamir, A. and Adleman, L, 
A method for Obtaining Digital Signatures of Public Key 
Cryptosystems, Communications of the ACM, 21 (2), 
1978: 120-1 26). The latter differsf ram symmetric encryp- 
tion, where the same key is used to both encrypt and 
decrypt a message. One of the advantages of such asym- 
metric methods isthat even if athird party is in possession 
of the key used to verify the message they cannot pro- 
duce the signature without the other key. If an encryption- 
decryption scheme is used, the encryption key is the ver- 
ifying key and the decryption key is the signing key. 
[0006] The most widely used public scheme, RSA, 
makes use of two very large prime numbers, and the fact 
that, at the time of writing, it takes a very long time to 



factor the product of these two primes back into the two 
original numbers. With sufficiently large numbers, RSA 
can therefore be highly resistant to signature falsification. 
Generally, one of the keys is the product n of the two 

s prime factors pa and q and a so-called public exponent 
e, and the other is a number derived from the pair of 
primes and e using modular arithmetic. The public expo- 
nent e must be chosen as mutually prime to p-1 and q- 
1 , and a secret exponent d may then be derived e.g. as 

10 the smallest positive integer satisfying ed - x(p-1)(q-1) = 
1 for some x using Euclid's algorithm repeatedly. 
Further information on this may be found in Menezes et 
al, mentioned above. 

[0007] Because knowledge of the key used for verifi- 
es cation does not enable signing, it is possible to broadcast 
this key (the so called "public key") as widely as possible, 
to as many people as possible, typically by providing a 
so-called Public Key Infrastructure (PKI, see CCITT 
(Consultative Comm. on Intern. Telegraphy and Teleph- 
20 ony), Recommendation X.509: The Directory — Authen- 
tication Framework, 1994, and Public Key Infrastructure: 
The PKIX Reference Implementation, Internet Task En- 
gineering Force) so that anyone can make use of it. 
[0008] If a particular public key can be used to verify 
25 a message, this shows that the originator of the message 
must have been the user holding the private key. It is 
therefore possible to indicate the origin of a particular 
message by making use of public key schemes. 
[0009] However, this therefore requires that there is 
30 some scheme in place to bind the identity of the user to 
a particular public key pair 

[0010] For example, the holdercould simply announce 
that he owns the public/private key pairto the world. How- 
ever, the recipient of the signed document would then 

35 only have the word of the holder as to his identity and 
that the holder is the owner, and that the key has not 
been compromised. In this case, the recipient of the mes- 
sage cannot verify that the sender of the message is be- 
ing truthful about their identity or ownership status, only 

40 that the message has come from someone claiming a 
particular identity and claiming to be the owner of the key 
pair. 

[001 1] Because of the above problems of verification 
of the identity and status of PKI key owners, third parties 

45 called Certification Authorities (CAs) have evolved to cer- 
tify that a particular user is who they claim to be. The 
user must supply certain credentials to the CA and his 
public key, and the CA in return issues a so-called cer- 
tificate, which is nothing but a signature generated by the 

50 CA on a message in a chosen format, such as X.509v3, 
consisting of the user's credentials and his public key. In 
addition, the CA must make a Directory available, from 
which the status of any user key can be communicated 
to any other user at any time, either by use of so-called 

55 revocation lists, or by online inquiry. Furthermore, the CA 
issues a Certificate Policy Statement, which states the 
rules for the users of the system, including the method 
by which the users have been identified. For details see 
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CCITT, and Public Key Infrastructure: The PKIX Refer- 
ence Implementation, mentioned above. 
[0012] A digital certificate, comprising a public key/pri- 
vate key pair has additional advantages over a traditional 
signature solution without certificates in that it may have 
a limited operational period and may also be suspended 
or revoked, should the private key of the user be com- 
promised, for example by being made available to a third 
party. In order for the signature to be of any use, it must 
preferably be represented in a standardised format, such 
as Public Key Crypto Standard (PKCS#1 ) signatures, for- 
matted according to CMS (the Cryptographic Message 
Syntax) (PKCS#7, for further information on which see 
PKCS #1 ,7, RSA Cryptography Standard, RSA Labora- 
tories, 2001). 

[001 3] As can be seen from above, it is vitally important 
that the private key of a signature be kept secure at all 
times, otherwise its value is removed, as its value lies in 
the fact that it certifies the identity of the author of a mes- 
sage by showing that the message originated from the 
owner of a particular key pair. This is only the case where 
the private key has not been compromised. Therefore, 
steps must be taken to maintain the security of the private 
key. 

[0014] One established approach to the protection of 
the private key of a key pair used for digital signatures is 
to use software solutions and then store it on the owner's 
workstation or a floppy disk protected by a pincode or 
passphrase controlled by the owner. However, it is gen- 
erally agreed that such a software-only solution is not 
sufficiently secure for high value transactions, unless the 
workstation is extraordinarily well protected. This is be- 
cause it will typically be possible to recover the private 
key using an exhaustive search for the password on the 
workstation, and in any case, it is difficult to protect the 
private key from so-called "Trojan horse" attacks. Here 
a malicious programme, a type of virus, is installed by an 
intruder, e.g. via an e-mail which contains an executable 
file, and this programme secretly copies the private key 
of the user when it is being used in the signature process, 
or it secretly copies the passphrase used to protect the 
private key. Measures can be introduced which make 
such attacks more difficult, but even so, they are still not 
easily prevented. For security and applicability reasons 
the physical protection offered by smartcards, which in 
addition provide a mobile solution, is attractive. The dis- 
advantage of this method is that it requires smartcard 
readers, which are still not widely available. 
[0015] An alternative, which for a long time was con- 
sidered very attractive, is instead to store the private key 
on asmartcard (chipcard). But this requires that the work- 
station used for the application must have a smartcard 
reader attached. As workstations very rarely have such 
a reader built-in as standard, and as there is no single 
dominating standard for communicating with the chip- 
card, the only possibility is to attach an external unit and 
install a driver on the workstation, which is both time con- 
suming and expensive. 



[0016] Identification and security are major issues for 
solutions that allow the user to generate a digital signa- 
ture. It is therefore an object of this invention to remove 
or ameliorate at least one of the problems associated 
s with the prior art. In particular, an object is to reach a high 
security level, while at the same time give a flexible so- 
lution to the problem. 

[0017] In addition, private keys stored on a workstation 
may appear "in the clear", that is in a non-encrypted form, 

10 in the user's computer's cache or printer cache or spool- 
er, or otherwise on an Internet Service Provider (ISP) 
cache, even if deleted from the user's computer. In fact, 
even deleted items can be recovered from a computer 
using specialised techniques to recover data from hard 

15 disk drives etc. Indeed, whenever the private key is used 
for signature generation, it has to be provided in unpro- 
tected form. 

[0018] Other solutions to the security problem allow 
the userto download their private key from a central serv- 

20 er and generate the signature on the workstation in soft- 
ware. This yields the mobility but it is still vulnerable to 
attacks if the workstation is insecure, which it typically is 
unless there are restrictions on which workstations can 
be used to download the private key. 

25 [0019] US 6,058,480 describes a system and method 
for authenticating users and services in which each user 
and service has a pass-phrase which is known to an au- 
thentication "deity". However this system is of no use in 
addressing the above-described problem of how to use 

30 the private key of a digital signature to sign data without 
putting the key at risk. 

[0020] I n an e m bod ime nt of th e p res e nt i nve nti on , th e 
private key of the user is stored centrally on a certifying 
apparatus consisting of one of more servers - not nec- 

35 essarily all at the same physical site. The servers are 
tamper resistant, typically employing a Hardware Secu- 
rity Module (HSM) such as an IBM 4758 with a limited 
command set available. One of these servers, called the 
signature server, contains the private keys of different 

40 users, initiated in such a way that only the rightful owner 
can initiate signature generation with his own private key. 
[0021] For further background material relating to dig- 
ital signatures reference may be made toTorben Peder- 
sen, Signature Server, NEWSONINK, [Online], January 

45 2004, URL: http://www.cryptomathic.com/pdf/ 
news5.pdf; Cryptomathic, 'Easy Sign - A User-Friendly 
Way of doing Mobile Commerce', Cryptomathic Web 
Site, [online], 6 th August 2001 (2001-08-06), 
XP002215193, URL: http://web.archive.orci/web/ 

50 2001080615; and also Cryptomathic, 'A New Approach 
to Digital Signatures', Cryptomathic Web Site [online], 
1 st August 2001 (2001-08-01), XP002215195, 
URL:http://web.archive.orglweb/2001 208011 50532/ht- 
tp://www.cryptomathic.comlnews/tech _frame_sig- 

55 serv.html. These describe use of a signature server to 
sign a document or more particularly a digest for hash 
value of a document, and the use of two independent 
channels of communication for non-repudiation. 
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[0022] The invention is as set out in independent 
claims 1, 10 and 33. 

[0023] We will describe a method of certifying electron- 
ic data supplied by a user, the method comprising receiv- 
ing the data to be certified at a certifying apparatus from 
a source device, certifying the data at the certifying ap- 
paratus with one or more elements of information secure 
to the certifying apparatus, said elements being unique 
to the user; and outputting the data so certified from the 
certifying apparatus, for passing to a recipient device; 
wherein the elements of secure information certify that 
the supplier of the data is the user. 
[0024] We will also describe a method of certifying 
electronic data supplied by a user, the method compris- 
ing: establishing a secure connection between a source 
device and a certifying apparatus; sending the data from 
the source device to be received by the certifying appa- 
ratus; and receiving a version of the data from the certi- 
fying apparatus certified as originating from the user, us- 
ing information unique to the user. 
[0025] The above method provides advantages of re- 
duced cost of administration of the certifying apparatus, 
increased ease of use for the users, and increased se- 
curity, as the information unique to the user never leaves 
the signature server of the certifying apparatus, whether 
in encrypted form or not. This allows the user to use mul- 
tiple workstations without carrying their private key to 
each workstation. Therefore, only a breach of the signa- 
ture server can result in the private keys being made 
available outside the signature server, which conse- 
quently must be prevented using tamper resistant hard- 
ware designed for the purpose, such as the IBM 4758. 
[0026] In more advanced scenarios, the private key 
could actually be distributed between any number N of 
servers using what is known as "secret sharing" in such 
as way that they each have a component of the key by 
which they can calculate an input for the generation of 
the signature, which is supplied back to the source de- 
vice, where the full digital signature is then calculated 
from K inputs where K is some number between 2 and 
N. The advantage of this is that at least K servers would 
have to be compromised before an attacker could calcu- 
late the private key. 

[0027] The certifying apparatus may include anything 
which is centrally based, and accessible from one or more 
source devices. Preferably, the certifying apparatus com- 
prises a signature server. Preferably, the certifying ap- 
paratus also comprises an authentication server. Prefer- 
ably, the certifying apparatus is accessible from many 
source devices. 

[0028] The source device may typically be a worksta- 
tion, but may also be an interactive television, or an Au- 
tomated Teller Machine for supplying cash or other in- 
formation from a central certifying apparatus. The source 
device will have all software required to communicate 
effectively with the certifying apparatus, but this could be 
supplied or downloaded to the source device for the re- 
quired duration of interaction only. The source device 



allows communication with the certifying apparatus. 
[0029] Preferably, the unique element or elements 
comprise the private key of a public key/ private key pair 
specific to the user. The unique element or elements may 

s generate a digital signature specific to the user, on data 
supplied by the user. Such PKI keys and digital signa- 
tures provide high security for the reasons given above, 
in that they are very hard and decrypt fraudulently. 
[0030] The recipient device may be the same as the 

10 source device, or, alternatively, it may be a third party 
device. The latter allows the whole message, or only a 
derived part, (preferably a hash value) of a message to 
be certified to be passed on to the required party without 
necessarily returning the certified message to the source 

15 device after certification. 

[0031] The third party device may be any appropriate 
device for receiving the certified data, other than the 
source device, such as a separate workstation, or a net- 
work of computers. For example, the third party device 

20 could be a gateway for a Local Area Network (LAN). Al- 
ternatively, the certifying apparatus andthird party device 
could be within a single LAN, or comprise a Wide Area 
Network (WAN). 

[0032] Preferably, the step of incorporating the certi- 
25 fied version of the data into further data to be sent to a 
third party device is included. 

[0033] Preferably, the certifying apparatus holds infor- 
mation unique to the user to carry out the certification. 
[0034] Preferably, the unique information is the private 

30 key of a public key / private key pair specific to the user. 
Also, preferably, the unique information is a digital sig- 
nature specific to the user. Preferably, the data to be 
certified is a hash value of a message. This gives the 
advantage that the whole message need not be sent to 

35 the signature server to be signed, so reducing the net- 
work traffic between the source device and signature 
server. 

[0035] Preferably, the source device and certifying ap- 
paratus establish an authenticated connection between 
40 them before and during transfer of the data to be certified. 
Additionally, the connection may be encrypted. This re- 
duces the possibility that the connection will be intercept- 
ed or interfered with. 

[0036] The source device may supply one or several 
<5 tokenstothecertifyingapparatusforauthentication. Pref- 
erably, one of the tokens is supplied to the userorsource 
device by the certifying apparatus via an alternate chan- 
nel to the authenticated connection. This also increases 
security significantly, by requiring two channels to be in- 
50 tercepted to fully access the data. 

[0037] The alternate channel could be a mobile tele- 
phone network channel. It is particularly preferred to use 
Short Message Service messages to convey the token. 
[0038] The token may be a fixed password in the most 
55 simple solution. In a preferred solution, the token is a 
one-time password, which has been communicated 
through an authenticated channel such as a mobile 
phone, or is calculated dynamically by means of a phys- 
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ical token which shares a key with the certifying appara- 
tus. Such solutions are generally available on the market, 
and examples are given below. 

[0039] Preferably, the token is unique to each trans- 
action, a transaction being the process of signing data, 
supplied by the source device, by the certifying device 
and supplying the signed data to a recipient device. The 
token may be stored on a portable device. 
[0040] Preferably, more than one type of token may 
authenticate the user or source device. For example, a 
fixed password may be used in addition to a one-time 
password generated by a physical token or sent to the 
user's mobile phone. The independence of these tokens 
makes it very difficult for an attacker to compromise both 
simultaneously. Thus such schemes are said to provide 
'strong' authentication of the user, and maybe employed 
to achieve a higher level of security than that obtained 
by use of a single authentication token alone. 
[0041] A further preferable feature is that the method 
operates with one level of security reached by authenti- 
cating the user regardless of the source device, and an- 
other, higher, level of security reached by authenticating 
the user and the source device. Preferably, the certifying 
apparatus certifies the data with different unique ele- 
ments, dependent upon the type of token used to authen- 
ticate the user or source device of security as well as the 
data. Such multiple level authentication allows different 
levels of security, and trust, to be placed on connections 
utilising different types of token, and different levels of 
signature to be used dependent on the token used. 
[0042] Where more than one type of token is used, 
perhaps simultaneously, to authenticate the user, it may 
be desirableto ensure that administration of these tokens 
is handled by separate independent groups of adminis- 
trate rs . To th is e n d , it is possi b le to co nf i g u re th e ce rtifyi n g 
apparatus as a group of more than one separate servers, 
and to have each server manage one or more independ- 
ent authentication tokens. 

[0043] One example of this is in the case where the 
user's private key is distributed using a secret sharing 
scheme between several servers. An alternative is for 
the user key to reside in a single server, known as the 
signature server, and for this to operate in conjunction 
with one or more other servers associated with user au- 
thentication, known as authentication servers. 
[0044] The user may establish separate connections 
to each server. It is also possible for the user to authen- 
ticate themselves using tokens managed by separate 
servers without having to establish separate connections 
to each server. An example of such a scheme is given 
in the description of an embodiment of the invention be- 
low. 

[0045] Preferably, validation data for validating the us- 
er and/or the data to be certified must be received by the 
certifying apparatus before the data can be certified. 
[0046] Preferably, the certifying apparatus sends a re- 
quest to a remote device to provide the user with identi- 
fication data. Further, the certifying apparatus may re- 



ceive a version of the identification data (for example a 
one-time password) from the remote device, and this ver- 
sion may be compared with further user data supplied 
from the user (for example a derived version of the one- 
s time password). Then, if the comparison is successful, 
the data to be certified is certified as originating from the 
user. 

[0047] A connection may be established between the 
workstation of the user and the remote device. This con- 
nection may be verified and authenticated independently 
of the connection between the workstation and the cer- 
tifying device/signature server. 
[0048] We also describe a method for use in certifica- 
tion of data comprising receiving a request from a remote 
device to supply a user with identification data, supplying 
said identification data to a user, and supplying a derived 
version of the identification data to the remote device. 
This method provides afurther channel for sending iden- 
tification data such as one-time passwords to a user. The 
method of transferring the identification data may be dif- 
ferent to the method used for transferring the request 
from the remote device, and the method of sending the 
derived version of the identification data. 
[0049] We also describe a computer apparatus pro- 
gramme to implement the above described methods and 
a computer readable carrier medium carrying code to, 
when running, cause a computerto implementthe meth- 
ods. 

[0050] We will further describe a data certifying appa- 
ratus, comprising a signing device adapted to certify data 
received from a remote source device as originating from 
a user, wherein the certifying apparatus is arranged to 
receive data from the source device, certify the data as 
belonging to the user, using information stored in the cer- 
tifying apparatus, said information being unique to the 
user, and send the certified data to a recipient device. 
[0051] Preferably, the recipient device is the source 
device. Alternatively, the recipient device may be a third 
party device. 

[0052] Preferably, the source device and certifying ap- 
paratus are arranged to establish an authenticated con- 
nection between them before and during transfer of the 
data to be certified. A further preferable feature is that 
the connection is encrypted. 

[0053] The source device may be arranged to supply 
a token to the certifying apparatus for authentication. 
Preferably, this token is supplied to the user or source 
by the authentication device via an alternate channel to 
the authenticated connection. The token may be a fixed 
password. Alternatively, the password may be a one time 
password. Again, the token may be unique to the trans- 
action. 

[0054] Preferably, in the apparatus of the present in- 
vention more than one type of token may authenticate 
the user and the source device. 
[0055] As a further preferable feature, the data certi- 
fying apparatus may be arranged to operate with one 
level of security reached by authenticating the user re- 
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gardless of the source device, and another, higher, level 
of security reached by authenticating the user and the 
source device, if oneparticularsource device, e.g. atrust- 
ed workstation is used. Additionally, the certifying appa- 
ratus may be arranged to certify the data with different 
unique elements, dependent upon the type of token used 
to authenticate the user or source device of security as 
well as the data. 

[0056] The certifying apparatus may also comprise in- 
structing means for sending a request to a remote device 
to instruct the remote device to send identification data 
(for example a one-time password) to the user. The cer- 
tifying apparatus may also comprise receiving means for 
receiving data derived from the identification data from 
the remote device. 

[0057] The derived data from the remote device may 
be compared with comparison means to further data re- 
ceived by the receiving means, and certifying means 
which certify the data to be certified if the data compared 
at the comparison means match. 

[0058] We also describe an apparatus for use in data 
certification, comprising receiving means for receiving a 
request from a remote device to supply a user with iden- 
tification data supplying means for supplying said iden- 
tification data to a user and further supplying means for 
supplying a derived version of the identification data to 
the remote device. 

[0059] Preferably, password generating means are al- 
so provided, which generate a password, for example a 
one-time password, although other identification data 
may also be generated. Preferably, the receiving means 
and further supplying means are arranged to operate via 
a different communication method to the supplying 
means. 

[0060] The embodiments and aspects of the invention 
described above are not only to be interpreted individu- 
ally nor solely in combination, but may be combined in 
any way in order to provide further embodiments of the 
invention. Additionally, individual features from an em- 
bodiment may be combined with other features from an- 
other embodiment so that various combinations of indi- 
vidual features from different embodiments and aspects 
also provide further embodiments of the invention. 
[0061] Specific embodiments of the present invention 
will now be described, purely by way of example, with 
reference to the drawings, in which: 

Figure 1 shows the architecture of the connections 
betwee n variouscomponents acco rdi n g to a f i rst e m- 
bodiment of the present invention; 

Figure 2 shows the steps involved in granting a user 
exclusive access to their signature key according to 
the first embodiment of the invention; 

Figure 3 shows a flow diagram of a method according 
to a first embodiment of the invention; 



Fig u re 4 s h ows a flow di ag ram of a metho d acco rdi n g 
to a further embodiment of the invention; and 

Figure 5 shows a flow diagram according to a further 
s embodiment of the present invention. 

[0062] Fig u re 1 sch em atical ly s h ows a system acco rd- 
ing to an embodiment of the present invention. It shows 
a user 102 operating a source device, which in the 

10 present embodiment is a workstation 1 01 , which is con- 
nected to a certifying device, which in the present em- 
bodiment is signature server 110, via a communication 
line 140. The communication line 140 is not inherently 
secure. The workstation 101 may be any terminal at 

15 which communication may be established with the sig- 
nature server 1 1 0. For example, the workstation 1 01 may 
be an interactive television set. The requirement is that 
the workstation 101 can communicate with the signature 
server 1 10. No special software is required at the work- 

20 station 101 side of the link. The signature server 110 
securely stores the private keys of each user and may 
additionally log some or all relevant information regarding 
users and their activities. The signature server 110 han- 
dles requests from users via the workstation 101 and 

25 may issue requests to a CA server. The signature server 
1 1 0 is ideally certified to an International standard, such 
as FIPS 140-1 level 3 or 4 (see FIPS Pub 140-1, 1994. 
National Institute of Standards & Technology, USA), 
which is a generally accepted standard to indicate the 

30 quality of the tamper resistance features of the hardware 
protection of the server. 

[0063] The signature server 1 1 0 receives data, which 
is to be verified as originating from the user, from the 
workstation 1 01 .Verification is achieved using the private 

35 key of the user, which is stored on the signature server 
1 1 0, to encrypt data received from the workstation 1 01 
and return that data to a recipient, which may be the user 
or athird party. Processes according to embodiments of 
the present invention will be described in more detail with 

40 reference to Figures 3, 4 and 5 below. 

[0064] The details of the hardware used in this embod- 
iment of the invention will now be described. In addition 
to the signature server 110, in an embodiment of the 
present embodiment the certification apparatus also has 

<5 a separate authentication server 120, which is enhanced 
by tamper resistant hardware just as the signature server 
1 1 0. Alternatively, the authentication server 120 may be 
remote to the signature server 1 1 0. The signature server 
1 1 0 is connected to the authentication server 120 via a 

50 strong cryptographic link 1 50 (i.e. encrypted and authen- 
ticated), for example by a shared master key, or based 
on public key encryption -decryption, using standard so- 
lutions, also sometimes known as a VPN (virtual private 
network). This is used to establish a session key and 

55 secure an encrypted channel between the servers using 
standard cryptographic techniques as is well known in 
the art. The key used might depend on the user password 
used for access. The secure tunnel 150 from authenti- 
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cation server 120 to signature server 110 continues into 
the hardware part of the signature server 110, in the 
sense that the keys used for this tunnel are controlled by 
tamper resistant hardware and never appear in the clear 
outside the certifying apparatus. The integrity of the sys- 
tem does not then have to rely so much on the secure 
area in which the server is placed. The same applies for 
all communication to and from both the signature server 
1 1 0 and authentication server 1 20. 
[0065] The authentication server 120 distributes one- 
time passwords and/or challenges to customers through 
an alternate channel 151. In the present embodiment, 
the alternate channel 151 employs SMS (short message 
service) messages sent via a cellular network for mobile 
phones for communicating the one-time passwords. Al- 
ternatively, the user might possess a handheld so-called 
secure token 1 90, a small device which shares an indi- 
vidual key with the authentication server 120. Once the 
challenge has been received via the workstation 1 01 , this 
is keyed in by the useron thetoken 190, andthe response 
which basically is an encryption of the challenge with the 
key held on the token 1 90, is keyed in at the workstation 
101 as the one-time password. The signature server 1 1 0 
may verify that the response is indeed an encryption of 
the challenge as it receives a derived version of the one 
time password from the authentication server 120. How- 
ever, many alternatives are available such as Wireless 
Application Protocol (WAP) over a cellular network 
(which is a specialised version of the Internet, and which 
can be accessed by WAP enabled mobile telephones), 
or ordinary paper mail. Alternatively, passwords may be 
distributed via the Internet, via an applet, which commu- 
nicates as directly as possible with a printer attached to 
the workstation 1 01 (as this limits the risk of password 
copies remaining in their printer/spooler buffers, or on 
the workstation 101 by means of Trojan horses which 
"sniff' the passwords). Examples of types of password 
that can be used in the present invention are discussed 
below. In any event, the exact nature of this authentica- 
tion process is not limited to that described, and many 
variations are possible within the context of the invention. 
[0066] At registration, a fixed password is forwarded 
in a secure way to the user 1 02 - which at any point in 
time he may change - so that each user 102 may be 
authenticated in a connection between a workstation 1 01 
and signature server 1 1 0 as part of the user authentica- 
tion process. In the present embodiment, in addition an 
on-line, one-time password is distributed via an SMS 
message from the authentication server 1 20 to the user's 
mobile phone (not shown). Such an on-line one-time 
password can have an extremely short validity period, 
which, togetherwith the authentication implied by the fact 
that the server knows how to locate the customer, gives 
high security to the password. The mobile telephone 
number of the user uniquely determines the user so the 
mobile telephone must be stolen, borrowed orclonedfor 
identification to fail, unless the SMS message is inter- 
cepted by someone who can at the same time make use 



of this information, which is relatively hard as the authen- 
tication channel is independent of the communication 
channel. 

[0067] This embodiment allows the user 1 02 to make 

s use of their digital signature, while ensuringthatthe digital 
signature itself never leaves the secure central certifying 
apparatus, whether encrypted, or not. 
[0068] The distribution of password-tokens according 
to an embodiment of the present invention will now be 

10 described using the elements shown in Figure 1. First, 
the user 1 02 contacts the signature server 1 1 0 from the 
workstation 101 via channel 152. The signature server 
1 1 0, via the secure link 1 50 established between signa- 
ture server 110 and authentication server 120, then in- 

15 structs the authentication server 1 20 to send out a one- 
time password to the user 1 02. The authentication server 
120 does this using SMS messaging, as described 
above, on channel 151. The authentication server 120 
also provides the signature server 110 with a derived 

20 version of the one-time password, via channel 1 50. This 
derived version is, in this embodiment, a hash value of 
the one-time password. The hash value is derived using 
a standard one way algorithm, such as SHA-1 (see Se- 
cure Hash Standard; FIPS Pub 180-1, 1995, National 

25 Institute of Standards &Technology, USA). A hash value 
is typically much smaller than the message from which 
it is so derived and, once the hash is calculated, the orig- 
inal message cannot be found from it. It is also very un- 
likely that two messages would have the same hash val- 

30 ue. This hash of the one-time password is then compared 
with the hash supplied by the workstation 1 01 . Since the 
same standard hashing algorithm is used by both the 
authentication server 120 and the workstation 101 , if the 
two hashes match then the user is accepted as being 

35 authenticated by the signature server 1 1 0. Alternatively, 
another type of derived version of the password can be 
sent to the signature server 1 1 0. The requirement is only 
that the process used to derive the version of the pass- 
word ortoken-response is the same in the authentication 

40 server 120 and workstation 101 so that a password will 
give the same derived version as authentication server 
1 20 and workstation 1 01 but two different passwords will 
not give the same result. 

[0069] The comparison of hash values allows the user 
<5 to be verified while the signature server 110 never re- 
ceives the actual one-time password. 
[0070] A variation to the distribution of password to- 
kens described above will now be described The user 
establishes independent connections to both the signa- 
50 ture server 1 1 0 and the authentication server 1 20, rather 
than only to the signature server 1 10. In this instance the 
data to be certified is sent to the authentication server 
120 through one interface and a hash value of the data 
to the signature server 110 through another interface. 
55 Alternatively, the hash value could be replaced by, or 
added to with, other related data. Typically, the data to 
be certified is generated at the source device on the basis 
of third party applications (e.g. a bank) through e.g. an 
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applet or applets, which then forwards the data and a 
hash on the data to the authentication server 120 and 
signature server 1 1 0 respectively. Each connection may 
be authenticated by use of a separate token, e.g. a fixed 
password for the signature server connection and a one- 
time password for the authentication server connection. 
The authentication server 120 forwards the data to be 
certified to the signature serve r1 10, which may compute 
a hash of the data and compare this with the hash re- 
ceived directly from the user 1 02. This scheme also pro- 
vides strong assurance at the signature server 1 10 that 
the user 1 02 has been authenticated by the authentica- 
tion server 1 20, but has the advantage that no information 
relating authentication server user authentication is re- 
ceived by or available to the signature server 1 1 0. 
[0071] The signature server 110 is supported by a 
tain per- resistant hardware security module (HSM) which 
has a protected cryptographic facility such as the IBM 
4758, where keys and signatures are generated, and if 
keys are not in use then they are stored externally, en- 
crypted under a master key. As shown in Figure 2, in an 
embodiment of the invention, initial data provided by the 
workstation 1 01 to the certifying apparatus is transferred 
to the HSM 1 1 1 via a channel 1 41 set up using the pass- 
word of the user 1 02 and standard encryption techniques. 
A second layer of encryption 1 40 extends from the work- 
station to the certifying apparatus, but does not extend 
into the HSM 111. This is a strong encrypted link with the 
authentication of the server, and this channel carries fur- 
ther information regarding details of the user 102 and 
specifying the authentication method to be used for the 
alternate channel 151 . The main point is that no sensitive 
key ever appears in the clear outside the secure box. 
Such solutions are widely used by e.g. the banking en- 
vironment, e.g. in connection with pincode-protection. 
The database 1 12 records all information regarding ad- 
ministrators. The HSM 1 1 1 handles storage of keys and 
cryptographic functionality. The signature server 1 1 0 is 
protected both by a firewall 180 and by physical security 
182 to prevent, reduce or deter unauthorised access. 
[0072] In an embodiment of the invention, the signa- 
ture server 110 is supported by clients ieo, 161, 162 
operated by trusted personnel e.g. under dual control, 
connected by an authenticated and encrypted link to the 
signature server 110. During a session between signa- 
ture server 1 1 0 and client, the administrator will first log 
on, and at this stage session keys to authenticate and 
encrypt all communication between the client 160, 161, 
162 and the signature server 110 is agreed using the 
master key, again using standard procedures for setting 
up a VPN between the client 1 60, 1 61 , 1 62 and the server. 
The necessary transport keys (master keys for exchange 
of session keys) are stored on smartcards, are operated 
by administrators and are used to administer (i.e. create/ 
enable/disable) security officer and clerk accou nts f orthe 
signature server 1 1 0, to browse the data in the signature 
server's 1 1 0 database and to register customers (those 
who have a signature on the server) on the signature 



server 110. 

[0073] In highly secure transactions, an embodiment 
of the invention offers further enhancement, to thwart at- 
tacks launched through the graphical user interface to 

s achieve what is known as WYSIWYS (What You See Is 
What You Sign): One simple possibility is to let the cer- 
tifying apparatus confirm essential parts of the data sup- 
plied by the user for certification via the second channel 
used for authentication purpose before the certification 

10 is carried out. In this instance the whole message to be 
certified has to be forwarded to the certifying apparatus 
for inspection. 

[0074] The security officers and the clerks are two lev- 
els of administrator of the signature server 1 1 0: the se- 

15 curity officer is responsible for all security related aspects 
of operating the signature server 110, including adding 
new administrators, exporting the audit log, and suspend- 
ing or disabling administrator accounts: The clerk is re- 
sponsible for user related activities such as registering 

20 new customers with the system, suspending/disabling 
customers, extracting reports about the customer activ- 
ities and the like. The two levels give increased security 
to the system by restricting access to some systems more 
than others. 

25 [0075] While two levels of signature server 1 10 admin- 
istrators have been given, it is possible to divide author- 
ised activities between any n umber of diffe rent structu res 
as required. For example, it is possible to allow the cus- 
tomer to perform simple administrative tasks such as is- 

30 suing new passwords, requesting reports on their activity 
or suspending his own account if fraudulent use is sus- 
pected. However, in the present embodiment accounts 
can only be re-enabled by a clerk and will result in a new 
password being sent from the authentication server 120 

35 to the customer via the user's mobile telephone. 

[0076] The authentication server 1 20 is also enhanced 
by a hardware security module 121 , and has a database 
122, in the same way as the signature server 1 10 and 
protected by a firewall 181 and physical security 183. 

40 The authentication server 1 20 is also connected with cli- 
ents 1 70, 171 , 1 72 using authenticated encrypted chan- 
nels as described above in relation to the signatu re server 
1 1 0 client links. For security, these clients 1 70, 1 71 , 1 72 
are separate to the clients 1 60, 1 61 , 162 administrating 

<5 the signature server 110. 

[0077] The signature server 110 and authentication 
server 120 is preferably housed geographically separat- 
ed and are each operated by an independent body with 
separate clients 1 60, 1 61 , 1 62 and 1 70, 1 71 , 1 72 admin- 

50 istering each. This reduces the possibility that there will 
be unauthorised access to both servers, which would be 
required if the private key of the user were to be misused. 
[0078] Alternatively, the authentication server 1 20 and 
signature server 110 may be housed in the same certi- 

55 tying apparatus. In such a case the administration clients 
1 60, 1 61 , 1 62, and 1 70, 1 71 , 1 72 for each server (e.g. 
the interface through which the server is operated) should 
preferably remain separate, so that increased security is 
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provided, by ensuring that access to both servers cannot 
be obtained through the same client, although they could 
be the same. The advantage of this single-server ap- 
proach is that this approach is simpler, as only one server 
is operated rather than two, but the disadvantage is that 
more care is required to assure that the trusted personnel 
cannot thwart the system in any way. 
[0079] As well as the on-line one-time password given 
so far in the present embodiment, a number of other types 
of password and delivery methods may be employed in 
addition to SMS messages distributing on-line one-time 
passwords. Authentication may be achieved by means 
of tokens 190 e.g. passwords, one-time passwords, 
stored secrets etc. The different types of token have dif- 
ferent properties regarding their mobility and security. 
For all types of password a key is generated for authen- 
ticating the request at the signature server 1 1 0. The sig- 
nature server 1 10 will generate the key in a similar way 
and verify the request. 

[0080] Fixed passwords are passwords which do not 
change, and can be used many times on different occa- 
sions to authenticate a user. Such fixed passwords are 
mobile, but less secure than one-time passwords be- 
cause they are easily eavesdropped, either by physically 
observing the customer when the password is entered, 
or by fooling the customer into entering the password in 
a false password prompt. It is not possible to determine 
whether a fixed password is compromised or not, but in 
case of suspected compromise (e.g. based on audit 
trails), the password can be disabled. 
[0081] Fixed passwords must originally be provided by 
the authentication server 120, to the user, via a secure 
channel (e.g. in a sealed envelope) because initially the 
user has no way of authenticating himself on the network. 
After the initial password has been received, the user 
may change the password online if sufficient authentica- 
tion and confidentiality is provided. 
[0082] Fixed passwords may be categorised by how 
susceptible they are for being compromised, such that 
one may have one password for controlled or secure en- 
vironments and another for less controlled or secure en- 
vironments. 

[0083] Alternatively, stored one-time passwords may 
be employed, which are mobile and saferthan fixed pass- 
words, but may be compromised by physical theft or by 
copying. Theft is easily detected whether the passwords 
are stored on print or in a mobile device. However, cop- 
ying is not detectable. 

[0084] Stored one-time passwords have a long validity 
period and must be transmitted securely from the authen- 
tication server 120 to the user. The copying of one time 
passwords must be prevented and this may be very hard 
to do if passwords are transmitted on-line over the Inter- 
net because they may reside in various cache files, print- 
er buffers etc. , for a long time afterthe user believes them 
to be erased. Cryptographically secured communication 
reduces the problem of obtaining the passwords during 
transmission to the user, but does not guarantee anything 



about plain text copies stored at the workstation. 
[0085] The on-line one-time passwords of the present 
embodiment are more secure than stored one-time pass- 
words due to the short validity period making theft and 

s subsequent use virtually impossible. However, intercep- 
tion of the alternate channel is still possible, although it 
is highly unlikely that both channels may be attacked by 
the same attacker at the same time, which is a strength 
of the approach. 

10 [0086] A further alternative is a terminal fingerprint, 
which may be used to identify a particular user's work- 
station 1 01 . It is a value that uniquely identifies the work- 
station 101. Such a fingerprint can be computed based 
on secrets stored on the workstation 101, the hardware 

15 configuration of the workstation 101 and all serial num- 
bers of hardware devices in the workstation 101 . How- 
ever, as a fingerprint can be forged by copying all this 
information, fingerprints are only relevant forterminals in 
controlled environments i.e. those having physical and 

20 software protection. Terminal fingerprints are notsuitable 
tokens in a situation where the customer uses many dif- 
ferent terminals, but rather for the situation where trust- 
worthy identification is required for a single terminal. 
Stealing a fingerprint requires a break-in or a hacker at- 

25 tack, but cannot be considered detectable. 

[0087] It would improve the security, if there is one se- 
cure trusted workstation 101 available to the user with a 
secure tunnel connection to the signature server 1 1 0 as 
well as the authentication server 120, in that this would 

30 enable the user e.g. to change his memorised password 
in a secure manner at any point in time from this particular 
work station. 

[0088] In a further alternative, a high level of security 
occurs when sessions with the signature server 110 are 

35 chained. This means that the server returns a token 190, 
which is stored on the workstation 101 and returned to 
the server on instigation of the next session. The token 
190 returned may or may not be distributed and kept 
securely but will always allow the customer to detect 

40 abuse of his signature, since the next session will fail 
authentication because the token will have been returned 
to the fraudulent user, ratherthan the legitimate one. This 
solution requires careful synchronisation between cus- 
tomer and server in order to ensure that tokens are not 

<5 lost in case connections fail. There are many known and 
well understood methods for dealing with this. 
[0089] A further, more secure token 190 is a crypto- 
graphic add-on for a computer, which allows complete 
identification of a workstation 1 01 by the use of a chal- 

50 lenge-response protocol. Although such add-ons may be 
physically small and flexible, they are not suited to use 
with multiple workstations 101 as their complete identifi- 
cation of a single workstation 1 01 is required. An example 
of this would be a small unit ("dongle") connected to the 

55 serial port of the workstation 1 01 , such as devices avail- 
able on the market for software and or information pro- 
tection. 

[0090] Handheld devices such as password genera- 
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tors and smart card front ends allow very trustworthy 
identification of the device in question, even though the 
device may be stolen just as any other device. Compared 
with terminal one-time passwords via SMS to another 
telephone, the advantage of a handheld cryptographic s 
device is that the SMS message may be eavesdropped 
or intercepted, whereas the cryptographic device may 
not be meaningfully so. 

[0091] The most secure means of identification may 
be the use of a physical attribute of the user such as a 10 
retinal or fingerprint scan. However, at the present time, 
such scanners are not widely available on any worksta- 
tion 101 through which a session may wish to be con- 
ducted. 

[0092] As communication with mobile units becomes is 
more advanced, it will be possible to adapt more and 
more advanced authentication channels, and these 
could equally be used, as long as they fulfil the require- 
ments of user authorisation and/or authentication. 
[0093] Obviously, various schemes discussed above 20 
will have various levels of security. The lowest level (level 
1) is where the user just memorises a password he 
shares with the signature server, which he includes 
whenever a signature must be generated. 
[0094] More advanced is the solution (level 2) where 25 
in addition he includes a one-time password which he 
has received previously via an independent authorised 
channel from the authentication server, e.g. an SMS 
message, a paper based list by ordinary mail, or com- 
municated to a secure work station through an encrypted 30 
tunnel and then printed out. At every new transaction, a 
new password is used in addition to a unique password 
memorised by the user. 

[0095] Even more advanced and flexible (level 3) is 
the situation where the user possesses a handheld token, 35 
such as a VASCO Digipass, or the RSA SecurelD Key 
Fob, which shares e.g. conventional key with the signa- 
ture server. When the user logs on, he either receives a 
so-called challenge from the certification device which 
he keys in on the token. The token then processes the 40 
challenge and returns a so-called response on its display, 
which is keyed in on the work station by the user as the 
one time password, and verified to be correct by the cer- 
tification device. Othertokens, generally available on the 
market as well, automatically calculate a new response 45 
at regular intervals using a key shared with the certifica- 
tion device, which may be varied without the use of a 
challenge, as the challenge is implicit to the system. 
[0096] For level 3, any sufficiently secure personal 
identification scheme based on tokens available on the 50 
market may in principle be incorporated into the invention 
in order to create the necessary authentication of the 
user. This token may also be a mobile device, which may 
communicate securely with the certification device e.g. 
using WAP-security for the receipt of one-time pass- 55 
words from the authentication server, or whichever com- 
munication security is available for that device, such as 
Bluetooth or infrared carried communication to some ter- 



minal connected to the authentication server through a 
physical network. Again the physical network need not 
be secure, as the communication is secured by means 
of asecure tunnel between the authentication server and 
the mobile device. 

[0097] A f u rth e r I eve I of sec u rity , f o r exam plefora fixed 
permanent trusted workstation 101 may be reached if a 
hardware cryptographic device is used to provide com- 
plete identification of the workstation 1 01 . For this level 
the workstation 101 could be bound to an IP-address or 
to a telephone number. 

[0098] Of course, many levels of access and security 
can be introduced as required with different properties 
and requirements. Advantages of the above embodi- 
ments are that the signature server 1 10 is used in such 
a way that the private key of a user is never transmitted 
outside of the secure signature server 110, whether or 
not encrypted. This means that substantially increased 
security is available protecting the private keys of users. 
[0099] Because it is possible to operate with different 
trust levels, depending on the authentication token 190 
or tokens supplied to the signature server 110, poorly 
identified sessions (i.e. those authenticated according to 
level 2) may be used for only signatures for transactions 
with small potential losses as a result of fraud (e.g. small 
bank transactions) whereas a more secure session (i.e. 
those authenticated according to level 3 or 4) such as 
the user's home PC, may be used for transactions with 
larger potential losses as a result of fraud, the embodi- 
ments of the present invention allow the combination of 
use of a secure fixed terminal system together with the 
mobility given by being able to use any workstation 1 01 . 
Therefore the advantages of each are given. 
[0100] When a customer wishes to be registered atthe 
signature server 110, he or she contacts a clerk, who 
takes care of the registration. If the customer wishes to 
be registered with a certificate, two options exist depend- 
ing on whether the CA and the signature server 110 are 
operated by the same organisation or not. 

1 . If both servers are operated by the same organi- 
sation, the client can be registered at the CA and at 
the signature server 1 1 0 simultaneously, and a key 
pair and a certificate can be generated immediately. 

2. If the servers are operated by different organisa- 
tions, the customer first needs to be registered atthe 
CAand perhaps receive a sender key ID and an IAK 
(Initial Authentication Key) then the customer can 
just be registered atthe signature server 110. If the 
customer is willing to reveal the sender ID and the 
IAK to the clerk, the key pair can be generated im- 
mediately as in case 1 , otherwise the key generation 
must be initiated via the internet. The registration 
procedure can be achieved using well known and 
understood methods, such as the International 
Standard PKIX, and would typically be the respon- 
sibility of the chosen CA. Certificates would only be 
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required when the certifying apparatus is receiving 
data to be certified from many source devices. If the 
source device is known then no external CA would 
be required. 

5 

[0101] Figure 3 shows a flow diagram of the steps in- 
volved when a message is signed with the user's private 
key held on the signature server 110. 
[0102] At S300 the message is entered onto a work- 
station 101 . The message may be manually entered at 10 
the workstation 1 01 . Alternatively, the message may be 
written at an earlier stage and stored elsewhere before 
being loaded onto the workstation 101. When the mes- 
sage is ready to be sent, in this embodiment the work- 
station 101 is connected to the Internet. However, direct is 
(point to point) connection between workstation and sig- 
nature server 1 1 0 may alternatively be used. The Internet 
is used to contact the signature server 1 1 0 over an inse- 
cure channel. At this stage, the signature server 1 1 0 and 
workstation 101 do not know to whom they are respec- 20 
tively connected. In order to determine this, verification 
of the communications is required at S302. Verification 
of the signature server 1 10 can be accomplished by the 
use of a public key/private key pair. The signature serv- 
er's 110 public key is published and available to the work- 25 
station 101 , for instance, from a CA. Various methods of 
establishing the identity of the server are then available 
that all involve the use of the server's private key to en- 
crypt or decrypt a message. Since the private key of the 
signature server 1 1 0 is known only tothe signatureserver 30 
1 1 0, the workstation 1 01 is able to identify messages as 
coming from the signature server 110. Also, using the 
signature server's 1 10 private key/public key pair, a se- 
cure tunnel is able to be set up from the workstation 1 01 
to the signature server 1 10 by the workstation 1 01 en- 35 
crypting with the server's public key and only the server 
being able to decrypt it with its private key. A wide variety 
of authentication and encryption processes, which are 
well known in the art, can be employed in the invention. 
In the present embodiment, the user is identified by use 40 
of a fixed password which is recognised by the signature 
server during the authentication process. 
[0103] However, at this stage, the signature server 1 10 
has not authenticated the workstation 1 01 as being used 
by a particular user of the certification system. The sig- 45 
nature server 1 10 needs to receive some secret from the 
workstation 101 , which is only known by the user in order 
to carry out authentication. This is done by the signature 
server 1 1 0 requesting that the authentication server 120 
send an on-line onetime password to the user over a 50 
separate channel to the link between the signature server 
1 10andthe workstation 1 10atS304. In this embodiment, 
this is done by an SMS message. The user subsequently 
enters it into the workstation 101 at S308, once it has 
been received. Because the connection from workstation 55 
101 to signature server 11 0 is secure in the direction from 
workstation 101 to signature server 110, eavesdropping 
will not identify the password entered and sent to the 



signature server 110. In addition, as stated above, the 
workstation 1 01 derives a hash value from the password, 
rather than sending the password over the connection at 
S310. The authentication server 120 sends its own ver- 
sion of the derived result to the signature server 1 10 at 
S312, and the signature server 1 1 0 compares both val- 
ues. If they are the same then it is very unlikely that an 
incorrect password was entered and the password is ver- 
ified at S3 14. 

[0104] Once the password has been verified, a bi-di- 
rectional secure channel is established at S31 6. This can 
be set up by using the secret (i.e. the password), which 
is sent to the signatureserver 1 1 0 with the signature serv- 
er's 1 1 0 public key to generate a session key. This secure 
channel is based on the usual principles of a VPN. 
[0105] Alternatively, one of the other forms of pass- 
word or token 190 discussed above may be used to au- 
thenticate the user depending on whether the user is at 
a secure workstation 101 or a non secure workstation 
101. 

[0106] As mentioned, the invention is not limited to any 
specific algorithms and methods to set up the security 
channel. The requirement is simply that a secure channel 
is established. In the case of the current embodiment, 
the secure channel is bi-directional. However, this need 
not be the case in general. 

[0107] Once the bi-directional secure channel has 
been established, the workstation 101 calculates a hash 
value of the message which the user wishes to be certi- 
fied at S31 8. This hash value is then sent overthe secure 
channel, to the signature server 1 1 0. Once the signature 
server 1 10 receives the hash value, it retrieves the private 
key of the user from the HSM and encodes the hash 
value with the user's private key at S320 (of course, the 
user's private key may be retrieved at any time after the 
user's identity is established). 

[0108] The signed hash is then returned to the work- 
station 101. This hash has now been encrypted using 
the private key of the user and so is certified as originating 
fromthatuser.Thishasbeenachi eved wi th 0 ut t he p ri vate 
key ever leaving a physically and software protected en- 
vironment of the signature server 110. Therefore, this 
embodiment of the invention overcomes the security dis- 
advantages by ensuring that the private key is never 
available outside the signature server 1 1 0. This increase 
in security of the private key results in an increased value 
of the certificate, as the message is more likely to be 
authentic. 

[01 09] The signed hash value is then embedded in the 
full original message at S322 and can then be sent over 
an insecure channel, such as the Internet, to a recipient 
S324. The message is certified as being from the owner 
of the digital signature. 

[01 1 0] Additionally, because in an embodiment of the 
invention the signature server 1 1 0 and the authentication 
server 120 are both used, and are preferably separated 
geographically, and because all three of workstation 1 01 , 
signature server 1 1 0 and authentication server 120 must 
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be involved in the certifying of the data from the worksta- 
tion 101, both the signature server and authentication 
server must be compromised in order to falsify a certifi- 
cation. The likelihood of this is reduced by the separation 
of the servers, and by independent administration of each 
server. 

[0111] An insecure channel maybe used to distribute 
the signed message, since the signed hash value acts 
both as an identifier and an authenticator of the message 
content. At S326 in Figure 3, the recipient checks with 
the certification authority used to issue the user's public 
key/private key pair, and receives the user's public key. 
This is used to decrypt the hash value of the message 
and so certify that the originator of the message is the 
user. In addition, the recipient can calculate the hash 
value of the message itself and checkthatthis hash value 
matches the encrypted hash value. If this is not the case, 
then the message has been tampered with and can be 
discarded. 

[0112] If the message is sent over an insecu re channel, 
while it will not be possible to tamper with the message 
without detection, it still may be possible to intercept and 
read the message before it is received by the recipient. 
In order to avoid this, a secure channel between user 
and recipient can be established using a method as de- 
scribed above, or any other suitable method. The secure 
channel need only be from the user to the recipients. The 
recipients need not establish a secure channel for infor- 
mation passing back to the user, unless sensitive or se- 
cret information is to be returned to the user from the 
recipient. 

[0113] Alternatively, in order to avoid the problem of 
third parties intercepting and reading the message be- 
tween user and recipient, a method as shown in Figure 
4 may be employed. 

[0114] This method is similar to that shown in Figure 
3. In S400 the message is entered into the workstation 
101. S402 toS416are as described above with reference 
to Figure 3, to establish a secure channel between work- 
station 101 and signature server 110. However, only a 
one-way secure channel need be established because, 
in this embodiment, the steps following establishment of 
a secure channel are different to the embodiment shown 
in Figure 3. This embodiment differs in that the whole 
message is sentfromtheworkstation 101 to the signature 
server 1 1 0 at S41 S. 

[0115] Therefore, no information requiring encryption 
need be returned to the workstation 1 01 from the signa- 
ture server 1 1 0. However, in practice, a bi-directional se- 
cure channel is preferably set up, to avoid misinformation 
fromthird parties regardingthe signature server 110, and 
its status, being sent to the workstation 101 . 
[0116] In this embodiment, the signature server 110 
uses the user's private key to encrypt the entire message 
as sent by the user. In addition, the user also supplies 
delivery details for the message to a recipient. At this 
stage, other than a notice of receipt of the message, the 
signature server 110 need not reply to the workstation 



101. 

[01 1 7] Once the message has been encrypted with the 
user's private key, the signature server 110 also adds 
the signature server's 110 signature, by encrypting with 

s the signature server's 1 1 0 private key, and forwards this 
encrypted message to the new recipient directly. The re- 
cipients can verify the message in the same way as dis- 
cussed with relation to Figure 3, except that the signature 
server's 110 public key is used, as well as the user's 

10 public key. Again, standard methods for encryption and 
signing are used here. 

[0118] Some, or all signature requests can have a 
summary field which is logged in the audit log. The pur- 
pose of the summary is to make it possible to extract 

15 meaningful reports over the customers' activities and al- 
low tracing, if a transaction is questioned. 
[0119] In addition, multiple request transactions may 
be supported wherein the usersupplies multiple requests 
for multiple signatures where each request must be sep- 

20 arately authenticated. This allows the customer to pre- 
pare a number of requests and have them all executed 
with a single log-on. If necessary, special network appli- 
cations may cache passwords in orderto provide a more 
user-friendly interface. 

25 [0120] The user can also request that a message or 
message hash is time-stamped and have a limited life- 
span. This is done using a flag in the signature request 
which determines whether a time-stamp should be sup- 
plied or not. Time stamping could, for example, be sup- 

30 ported by contacting a time stamp server via the PKIX 
TSP protocol, where a received signature on some mes- 
sage, or the concatenation of a number of signatures is 
sent to an independent third party offering independent 
timestamping. A timestamp is then added, and a signa- 
ls ture is generated on the message consisting of the re- 
ceived signatures and the timestamp. 
[01 21 ] An alternative method to that described with ref- 
erence to Figures 3 and 4 above will be described with 
reference to Figure 5. 

40 [0122] The system and method is especially useful 
where the signature and authentication servers 1 10, 120 
are geographically separated and administered by inde- 
pendent bodies. All other features may be as either de- 
scribed with reference to Figures 3 and 4. 

<5 [0123] The data to be signed is entered on the work- 
station at S500. An application or other program down- 
loaded from a third party to the workstation 101 . In this 
embodiment, the workstation runs the applet or program, 
which connects to both the signature server 1 1 0 and au- 

50 thentication server 120. The signature server 110 re- 
quests and receives the fixed password from the user 
102 (as described in regard to registration above) at 
S502. An authorised connection with the signatu re server 
1 1 0 is then established at S504 as described before with 

55 reference to S302 described above. 

[01 24] The signature server 1 1 0 then requests the au- 
thorisation server 120 to send a one-time password to 
the user via a different channel at S506 as in S304 de- 
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scribed above. 

[0125] The one-time password is sent to the user at 
S508 who enters it across the connection established 
between workstation 101 and authorisation server 120 
atS510. Averified connection istherefore set up between 
both workstation 1 01 and signature server 1 10, and work- 
station 101 and authentication server 120 at S512. 
[0126] The data to be certified is sent to the authenti- 
cation server 120 through one connection at S514, and 
a derived value (in this embodiment a hash value of the 
data, as described above) of the data to be certified is 
sent to the signature server 1 1 0 at S51 6. 
[0127] The authentication server 120 sends the data 
to be certified to the signature server, which computes 
the hash of the data to produce a derived value for com- 
parison with the derived value sent direct from the work- 
station. 

[0128] The two derived values are then compared by 
the signature server 1 1 0 at S51 8, which ensures that the 
two servers are connected to the same user. 
[01 29] The signature server 1 1 0 can then sign the data 
received from the authentication server 120 and return 
it to the workstation 1 01 , or forward to a third party recip- 
ient. 

[01 30] It is also possible that the derived version of the 
data be sent to the authentication server 120 and the 
actual data sent to the signature server 1 10. However, 
this is not preferred as the signature server 1 1 0 is then 
in possession of the data to be signed before the authen- 
tication server 1 20 authenticates it and the system could 
therefore be abused if illegitimate control of the signature 
server 1 1 0 was obtained. 

[0131] As well as using the one-time password issued 
by the authentication server 120 to authenticate the con- 
nection between the workstation 101 and signature serv- 
er 11 0, as described above, it is also possible to use a 
token to validate the connection between workstation 1 01 
and signature server 110, in the case of Figure 4, and 
separate tokens to validate the connections between the 
workstation 101 and each server in the case of Figures. 
In this alternative validation procedure, the two channels 
are established completely independently, which is es- 
pecially useful where the signature and authentication 
servers 110, 120 are separated geographically and ad- 
ministrated separately. 

[0132] The embodiments provide a certification meth- 
od wh i ch me ets th e req u i rem e nts fo r ade q u ate p rotecti o n 
of the private key e.g. to meet the requirements in the 
Directive of the European Union on qualified certificates; 
allows the genuine owner to initiate the generation of a 
digital signature from any appropriate workstation 101 
connected to some appropriate network, such as the In- 
ternet, without ever compromising the signature key, yet 
at the same time prevents anyone with total control over 
a workstation 101 which has been used as described 
above to subsequently have a new signature generated 
by means of the key of that owner. 
[0133] Although the above embodiments have been 



described in relation to a workstation and server, any 
situation where a message needs to be signed with a 
digital signature without the private key of a user leaving 
a secure server will also fall within this invention. Also, 

s the terms server, client and workstation used herein are 
not limited to the narrow meaning of the terms. A server 
may be any computer or the like, which can be contacted 
as a central unit by a number of workstations. A work- 
station is in interface between the user and the server, 

10 which transmits the electronic data and passwords, if re- 
quired, to the server. Clients are simply interfaces, which 
allow administration of a server. 
[0134] The present invention has been described 
above purely by way of example, and modifications can 

15 be made. The invention also consists in any individual 
features described or implicit herein or shown or implicit 
in the drawings or any combination of any such features 
or any generalisation of any such features or combina- 
tion, which extends to equivalents thereof. 

20 

Claims 

1 . A method of certifying electronic data supplied by a 
25 user, the method comprising: 

receiving data supplied by the userto be certified 
at a certifying apparatus (110) from a source de- 
vice (101); 

30 sending a request to a remote device (120) in- 

structing the remote device to send a password 
to the user, 

receiving a hash value derived from the pass- 
word from the remote device; 
35 receiving a further hash value from the user, 

comparing the further hash value from the user 
with the hash value from the remote device to 
thereby validate the user; 
certifying the data at the certifying apparatus 
40 (1 1 o) with one or more elements of information 

secure to the certifying apparatus, said ele- 
ments being unique to the user, if the further 
hash value corresponds to the hash value de- 
rived from the remote device; and 
<5 outputting the data so certified from the certifying 

apparatus (1 10), for passing to a recipient de- 
vice; 

wherein the elements of secure information certify 
50 that the supplier of the data is the user. 

2. A method as claimed in claim 1 further comprising 
authenticating a connection between said source de- 
vice and said certifying apparatus using afixed pass- 

55 word recognised by said certifying apparatus; and 
establishing a secure channel between said source 
device and said certifying apparatus by using a said 
hash value received by said certifying apparatus to- 
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gether with a public key of said certifying apparatus 
to generate a session key for said secure channel. 

3. A method as claimed in claim 1 or 2 further compris- 
ing establishing an encrypted channel between said s 
remote device and said certifying apparatus, where- 
in said certifying apparatus and said remote device 
include tamper resistant hardware (111,121), and 
wherein said encrypted channel comprises a secure 
tunnel (150) between said remote device and said 10 
certifying apparatus such that keys used for the tun- 
nel are controlled by said tamper resistant hardware 
and do not appear in clear outside said certifying 
apparatus. 

15 

4. A method according to claim 1, 2 or 3 wherein the 
private key of a public key/ private key pair specific 
to the user defines a said element unique to the user 



5. A method according to any preceding claim wherein 20 
a digital signature specific to the user defines a said 
element unique to the user. 

6. A method according to any preceding claim, wherein 

the recipient device is the source device. 25 

7. A method according to any one of claims 1 to 6 
wherein the recipient device is a third party device. 

8. A method according to any preceding claim, wherein 30 
a hash value of a message to be certified is gener- 
ated at the source device, the hash value being the 
data to be certified by the certifying apparatus. 

9. A method according to any preceding claim, wherein 35 
the certifying apparatus is adapted to receive data 
from a plurality of different source devices. 

1 0. A method of certifying electronic data supplied by a 
user, the method comprising: 40 

establishing a secure connection between a 
source device (1 01 ) operated by the user and a 
certifying apparatus (110); 

sending data supplied by the user from the 45 
source device (101) to be received by the certi- 
fying apparatus (110); 
receiving a password from a remote device; 
sending a hash value of said password to said 
certifying apparatus; and so 
receiving at the source device a version of the 
datafrom the certifying apparatus (110) certified 
as originating from the user, using information 
unique to the user. 

55 

1 1 . A method as claimed in claim 1 0 further comprising 
authenticating a connection between said source de- 
vice and said certifying apparatus usi ng a fixed pass- 



word recognised by said certifying apparatus; and 
establishing a secure channel between said source 
device and said certifying apparatus by using said 
hash value together with a public key of said certify- 
ing apparatus to generate a session key for said se- 
cure channel. 

12. A method according to claim 1 0 or 1 1 , further com- 
prising the step of incorporating a certified version 
of the data into further data to be sent to a third party 
device. 

13. A method according to claim 10, 11 or 12 wherein 
the certifying apparatus holds information unique to 
the user to carry out the certification. 

14. A method according to claim 13, wherein the unique 
information is the private key of a public key/private 
key pair specific to the user. 

15. A method according to claim 13 or 14, wherein the 
unique information is a digital signature specific to 
the user. 

16. A method according to any of claims 1 0to 15, where- 
in the data to be certified is a hash value of a mes- 
sage. 

1 7. A method according to any preceding claim, wherein 
the certifying apparatus comprises a signature serv- 
er (110). 

1 8. A method according to any preceding claim, wherein 
the certifying apparatus comprises a plurality of sig- 
nature servers using secret sharing to store individ- 
ual portions of a private key of a user, and wherein 
the signature is generated based on individual por- 
tions of a private key of a user stored on some or all 
of the signature servers. 

19. A method according to claim 17 or 18, wherein the 
certifying apparatus further comprises one or several 
authentication servers (120). 

20. A method according to any preceding claim, wherein 
the source device (101) comprises a workstation. 

21. A method according to claim 20 further comprising 
establishing an independent verified and authenti- 
cated communication channel between the worksta- 
tion and the remote device. 

22. A method according to any one of claims 1 to 19, 
wherein the source device comprises an interactive 
television. 

23. A method according to any preceding claim, wherein 
the source device and certifying apparatus establish 
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authenticated individual connections between the 
source device and one or several servers of the cer- 
tifying apparatus before and during transfer of the 
data to be certified. 

5 

24. A method according toclaim 23, wherein the method 
operates by authenticating the user regardless of the 
source to provide a first level of security, and oper- 
ates by authenticating the user and the source de- 
vice to provide a second level of security higher than 10 
the first level of security. 

25. A method according to claims 1 or 10, wherein the 
source device supplies a token (190) to the certifying 
apparatus for authentication, and wherein the certi- is 
fying apparatus certifies the data with different 
unique elements, dependent upon the type of token 
used to authenticate the user or source device. 

26. A method according to any preceding claim, wherein 20 
validation data for validating the data to be certified 

is received from a remote device before the data is 
certified. 



a signing device (110, 111) adapted to certify 
electronic data received from a remote source 
device (101) as originating from a user, wherein 
the certifying apparatus is arranged to receive 
data from the source device, certify the data as 
belonging to the user, using information stored 
in the certifying apparatus and cryptographic 
techniques, said information being unique to the 
user, and send the certified data to a recipient 
device; and further comprising instructing 
means for sending a request to a further remote 
device instructing the further remote device to 
send a password to the user; receiving means 
for receiving a hash value derived from the pass- 
word from the further remote device and for re- 
ceiving a further hash valuefrom the user, com- 
paring means for comparingthe further hash val- 
ue from the user with the hash value from the 
further remote device; and certifying means 
(110,1 11) for certifying the data to be certified if 
the further hash value from the user data corre- 
sponds to the hash value from the further remote 
device. 



10 



27. A method according to any preceding claim, further 25 
comprising the certifying apparatus sending the re- 
quest to the remote device after receiving a request 

to certify data. 

28. A method according to any of claims 1 to 27, further 30 
comprising: 

receiving a request from said certifying appara- 
tus at said remote device to supply the user with 
said password; 35 
supplying said password to the user, and 
supplying said hash value derived from said 
password to the certifying apparatus. 

29. A method according to any preceding claim wherein 40 
said password is a one-time password. 

30. A method according to claim 28 or 29, wherein the 
request and said hash value derived from said pass- 
word are transferred via a different communication 45 
method to said password. 

31. A computer readable medium storing instructions 
that when executed by a computer causes the com- 
puter to perform each of the method steps of any 50 
one of claims 1 to 9. 

32. A computer readable medium storing instructions 
that when executed by a computer causes the com- 
puter to perform each of the method steps of any 55 
one of claims 1 0 to 30. 

33. A data certifying apparatus (110, 120) comprising: 



34. A data certifying apparatus according to claim 33 
comprising means for authenticating a connection 
between said source device and said certifying ap- 
paratus using a fixed password recognised by said 
certifying apparatus; and means for establishing a 
secure channel between said source device and said 
certifying apparatus by using a said hash value re- 
ceived by said certifying apparatus together with a 
public key of said certifying apparatus to generate a 
session key for said secure channel. 

35. A data certifying apparatus according to claim 33 or 
34 further comprising means for establishing an en- 
crypted channel between said remote device and 
said certifying apparatus, wherein said certifying ap- 
paratus and said remote device include tamper re- 
sistant hardware (111,121), and wherein said en- 
crypted channel comprises a secure tunnel (1 50) be- 
tween said remote device and said certifying appa- 
ratus such that keys usedforthe tunnel are controlled 
by said tamper resistant hardware and do not appear 
in clear outside said certifying apparatus. 

36. A data certifying apparatus according to claim 33, 
wherein the certifying apparatus comprise means for 
establishing an authenticated connection with the 
source device before and during transfer of the data 
to be certified. 

37. A data certifying apparatus according to claim 36, 
wherein said authenticated connection is encrypted. 

38. A data certifying apparatus according to claim 36 or 
37, wherein the certifying apparatus comprises 
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means for accepting a token from the source device 
for authentication, and wherein the certifying appa- 
ratus comprises means for using more than one type 
of token to authenticate the user or source device. 

39. A data certifying apparatus according to claim 38, 
wherein the data certifying apparatus is arranged to 
operate by authenticating the user regardless of the 
source device to provide a first level of security, and 
to operate by authenticating the user and the source 
device to provide a second level of security higher 
than the first level of security. 

40. The data certifying apparatus according to claim 36 
or 37, wherein the source device comprises means 
forsupp lying a token (1 90) tothe certifying apparatus 
for authentication, and wherein the certifying appa- 
ratus comprises means for certifying the data with 
different unique elements, dependent upon the type 
of token used to authenticate the user or source de- 
vice. 

41. A data certifying apparatus according to any of 
claims 33 to 40, wherein the certifying apparatus 
comprises a signature server (1 1 0). 

42. A data certifying apparatus according to claim 41, 
wherein, the certifying apparatus comprises a plu- 
rality of signature servers, each signature server be- 
ing arranged to use secret sharing to store individual 
shares of a private key of a user, wherein, the sig- 
nature generated. 

43. A data certifying apparatus according to claim 41 or 
42, wherein the certifying apparatus further compris- 
es an authentication server (120). 



Patentanspruche 

1. Verfahren zur Zertifizierung von elektronischen Da- 
ten, die von einem Benutzer geliefert werden, das 
Verfahren umfassend: Empfangen dervon dem Be- 
nutzer gelieferten Daten, die zu zertifizieren sind, an 
einer Zertifizierungsvorrichtung (110) von einem 
Quellengerat (101); 

Senden einer Anfrage zu einem entfernten Gerat 
(1 20), die das entfernte Gerat anweist, ein Kennwort 
an den Benutzer zu senden; 

Empfangen eines Hash-Werts, abgeleitet von dem 
Kennwort von dem entfernten Gerat; 
Empfangen eines weiteren Hash-Werts von dem Be- 
nutzer; 

Vergleichen des weiteren Hash-Werts von dem Be- 
nutzer mit dem Hash-Wert von dem entfernten Ge- 
rat, um den Benutzer dadurch zu validieren; 
Zertifizieren der Daten an derZertifizierungsvorrich- 
tung (110) mit einem oder mehreren Elementen von 



Informationen, die fur die Zertifizierungsvorrichtung 
sicher sind, wobei die Elemente fur den Benutzer 
eindeutig sind, wenn derweitere Hash-Wert mit dem 
von dem entfernten Gerat abgeleiteten Hash-Wert 

s korrespondiert; und 

Ausgeben der derartzertifizierten Daten von derZer- 
tifizierungsvorrichtung (1 1 0) zur Weiterleitung zu ei- 
nem empfangenden Gerat; 
wobei die Elemente von sicheren Informationen zer- 

10 tifizieren, dass der Lieferant der Daten der Benutzer 
ist. 

2. Verfahren nach Anspruch 1, weiter umfassend die 
Authentifizierung einer Verbindung zwischen dem 

15 Quellengerat und der Zertifizierungsvorrichtung un- 
ter Verwendung eines festen Kennworts, das von 
derZertifizierungsvorrichtungerkanntwird; und Her- 
stellen eines sicheren Kanals zwischen dem Quel- 
lengerat und der Zertifizierungsvorrichtung unter 

20 Verwendung eines solchen Hash-Werts, dervon der 
Zertifizierungsvorrichtung empfangen wurde, zu- 
sammen mit einem offentlichen Schlussel der Zerti- 
fizierungsvorrichtung zum Generieren eines Sit- 
zungsschlussels fur den sicheren Kanal. 

25 

3. Verfahren nach Anspruch 1 oder 2, weiter umfas- 
send die Herstellung eines verschlusselten Kanals 
zwischen dem entfernten Gerat und der Zertifizie- 
rungsvorrichtung, wobei die Zertifizierungsvorrich- 

30 tung und das entfernte Gerat gegen Eingriffe wider- 
standsfahige Hardware (1 1 1,121)enthalten undwo- 
bei der verschliisselte Kanal einen sicheren Tunnel 
(150) zwischen dem entfernten Gerat und der Zerti- 
fizierungsvorrichtung umfasst, so dass Schlussel, 

35 diefiirdenTunnelverwendetwerden, von dergegen 
Eingriffe widerstandsfahigen Hardware kontrolliert 
werden und nicht unverschliisselt auBerhalb der 
Zertifizierungsvorrichtung erscheinen. 

40 4. Verfahren nach Anspruch 1 , 2 oder 3, wobei der pri- 
vate Schlussel eines fur den Benutzer spezifischen 
Paars aus einem offentlichen Schliissel/privaten 
Schlussel ein solches Element definiert, das fur den 
Benutzer eindeutig ist. 

45 

5. Verfahren nach einem dervorstehenden Anspriiche, 
wobei eine fur den Benutzer spezifische digitale Si- 
gnatures solches Element definiert, dasfurden Be- 
nutzer eindeutig ist. 

50 

6. Verfahren nach einem dervorstehenden Anspriiche, 
wobei das empfangende Gerat das Quellengerat ist. 

7. Verfahren nach einem der Anspriiche 1 bis 6, wobei 
55 das empfangende Gerat das Gerat einer dritten Par- 

tei ist. 

8. Verfahren nach einem dervorstehenden Anspriiche, 
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wobei ein Hash-Weit einerzu zertifizierenden Nach- 
richt an derm Quellengerat generiert wird und der 
Hash-Wert die Daten darstellt, die von der Zertifizie- 
rungsvorrichtung zu zertifizieren sind. 

9. Verfahren nach einem dervorstehenden Anspruche, 
wobei die Zertifizierungsvorrichtung zum Empfan- 
gen von Daten von einer Pluralitat von verschiede- 
nen Quellengeraten angepasst ist. 

10. Verfahren zur Zertifizierung von elektronischen Da- 
ten, die von einem Benutzer geliefert werden, das 
Verfahren umfassend: 



1 1 . Verfahren nach Anspruch 1 0, weiter umfassend die 
Authentifizierung einer Verbindung zwischen dem 
Quellengerat und der Zertifizierungsvorrichtung un- 

ter Verwendung eines festen Kennworts, das von 35 
der Zertifizierungsvorrichtung erkannt wird; und Her- 
stellung eines sicheren Kanals zwischen dem Quel- 
lengerat und der Zertifizierungsvorrichtung unter 
Verwendung des Hash-Werts zusamrmen mit einem 
offentlichen Schliissel der Zertifizierungsvorrichtung 40 
zum Generieren eines Sitzungsschlussels fur den 
sicheren Kanal. 

1 2. Verfahren nach Anspruch 1 0 oder 1 1 , weiter umfas- 
send den Schritt der Inkorporierung einer zertifizier- 45 
ten Version der Daten in weitere Daten, die zu einem 
Gerat einer dritten Partei zu senden sind. 

1 3. Verfahren nach Anspruch 1 0, 11 oder 1 2, wobei die 
Zertifizierungsvorrichtung Information en, diefurden 50 
Benutzer eindeutig sind, zum AusfCihren der Zertifi- 
zierung enthalt. 

1 4. Verfahren nach Anspruch 1 3, wobei die eindeutigen 
Informationen der private Schliissel eines fur den 55 
Benutzer spezifischen Paars von einem offentlichen 
Schliissel/privaten Schliissel sind. 



15. Verfahren nach Anspruch 13 oder 14, wobei die ein- 
deutigen Informationen eine fur den Benutzer spe- 
zifische digitale Signatursind. 

16. Verfahren nach einem der Anspruche 10 bis 15, wo- 
bei diezu zertifizierenden Daten ein Hash-Wert einer 
Nachricht sind. 

17. Verfahren nach einem dervorstehenden Anspruche, 
wobei die Zertifizierungsvorrichtung einen Signatur- 
server (1 10) umfasst. 

18. Verfahren nach einem dervorstehenden Anspruche, 
wobei die Zertifizierungsvorrichtung eine Pluralitat 
von Signaturservern umfasst, die geheime gemein- 
same Nutzung anwenden zur Speicherung von in- 
dividuellen Anteilen eines privaten Schliissels eines 
Benutzers, und wobei die Signatur generiert wird auf 
der Basis von individuellen Anteilen eines privaten 
Schliissels eines Benutzers, der auf einigen oder al- 
ien der Signaturserver gespeichert ist. 

19. Verfahren nach Anspruch 17 oder 18, wobei die Zer- 
tifizierungsvorrichtung weiter einen oder mehrere 
Authentifizierungsserver (120) umfasst. 

20. Verfahren nach einem dervorstehenden Anspruche, 
wobei das Quellengerat (101) eine Arbeitsstation 
umfasst. 

21. Verfahren nach Anspruch 20, weiter umfassend die 
Herstellung eines unabhangig verifizierten und au- 
thentifizierten Kommunikationskanals zwischen der 
Arbeitsstation und dem entfernten Gerat. 

22. Verfahren nach einem der Anspruche 1 bis 19, wobei 
das Quellengerat ein interaktives Fernsehen um- 
fasst. 

23. Verfahren nach einem dervorstehenden Anspruche, 
wobei das Quellengerat und die Zertifizierungsvor- 
richtung vor und wahrend der Obertragung der zu 
zertifizierenden Daten authentifizierte individuelle 
Verbindungen zwischen dem Quellengerat und ei- 
nem oder mehreren Servern der Zertifizierungsvor- 
richtung herstellen. 

24. Verfahren nach Anspruch 23, wobei das Verfahren 
durch Authentifizierung des Benutzers unabhangig 
von der Quelle arbeitet, um eine erste Sicherheits- 
stufe bereitzustellen, und durch Authentifizierung 
des Benutzers und des Quellengerats arbeitet, um 
eine zweite Sicherheitsstufe, die hdher ist als die er- 
ste Sicherheitsstufe, bereitzustellen. 

25. Verfahren nach Anspruch 1 oder 10, wobei das Quel- 
lengerat einen Token (190) an die Zertifizierungs- 
vorrichtung zur Authentifizierung liefert und wobei 



Herstellen einer sicheren Verbindung zwischen is 
einem Quellengerat (101), das von dem Benut- 
zer bedient wird, und einer Zertifizierungsvor- 
richtung (110); 

Senden der von dem Benutzer gelieferten Daten 
von dem Quellengerat (1 01 ), die von der Zerti- 20 
fizierungsvorrichtung (1 10) zu empfangen sind; 
Empfangen eines Kennworts von einem ent- 
fernten Gerat; 

Senden eines Hash-Werts von dem Kennwort 
zu der Zertifizierungsvorrichtung; und 25 
Empfangen an dem Quellengerat einer Version 
der Daten von der Zertifizierungsvorrichtung 
(1 10), zertifiziert wie von dem Benutzer ausge- 
hend, unter Verwendung von Informationen, die 
fur den Benutzer eindeutig sind. 30 
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die Zertifizierungsvorrichtung die Daten mit ver- 
schiedenen eindeutigen Elementen zertifiziert, ab- 
hangig von dem Typ des Tokens, der zur Authenti- 
fizierung des Benutzers oderQuellengerats verwen- 
detwird. s 

26. Verfahren nach einem dervorstehenden Anspruche, 
wobei Validierungsdaten zum Validieren der zu zer- 
tifizierenden Daten von einem entfernten Gerat emp- 
fangen werden, bevor die Daten zertifiziert werden. 10 

27. Verfahren nach einem dervorstehenden Anspruche, 
we iter umfassend, dass die Zertifizierungsvorrich- 
tung die Anfrage an das entfernte Gerat sendet, 
nachdem sie eine Anfrage zurZertifizierung von Da- is 
ten empfangen hat. 

28. Verfahren nach einem der Anspruche 1 bis27,weiter 
umfassend: 

20 

Empfangen einer Anfrage von der Zertifizie- 
rungsvorrichtung an dem entfernten Gerat zur 
Belieferung des Benutzers mit dem Kennwort; 
Liefern des Kennworts an den Benutzer; und 
Liefern des von dem Kennwort abgeleiteten 25 
Hash-Werts an die Zertifizierungsvorrichtung. 

29. Verfahren nach einem dervorstehenden Anspruche, 
wobei das Kennwort ein Einmal-Kennwort 1st. 

30 

30. Verfahren nach Anspruch 28 oder29, wobei die An- 
frage und der von dem Kennwort abgeleitete Hash- 
Wert iiberein anderes Kommunikationsverfahren zu 
dem Kennwort ubertragen werden. 

35 

31. Computer-lesbares Medium, das Anweisungen 
speichert, die bei Ausf uhrung durch einen Computer 
bewirken, dass der Computer jeden der Verf ah rens- 
schritte von irgendeinem der Anspruche 1 bis 9 aus- 
fuhrt. 40 

32. Computer-lesbares Medium, das Anweisungen 
speichert, die bei Ausf uhrung durch einen Computer 
bewirken, dass der Computer jeden der Verf ah rens- 
schritte von irgendeinem der Anspruche 10 bis 30 45 
ausfiihrt. 

33. Datenzertifizierungsvorrichtung (110, 120), umfas- 
send: 

50 

Signierungsgerat(1 10, 11 1),angepasstzurZer- 
tifizierungelektronischer Daten, empfangen von 
einem entfernten Quellengerat (101) wie von ei- 
nem Benutzer ausgehend, wobei die Zertifizie- 
rungsvorrichtung angeordnet ist zum Empfan- 55 
gen von Daten von dem Quellengerat, Zertifizie- 
ren der Daten als zu dem Benutzer gehorend, 
Verwendung von Informationen, die in der Zer- 



tifizierungsvorrichtung gespeichert sind, und 
Kryptotechniken, wobei die Informationen ein- 
deutig fur den Benutzer sind, und Senden der 
zertifizierten Daten zu einem empfangenden 
Gerat; und weiter umfassend Anweisungsmittel 
zum Senden einer Anfrage zu einem weiteren 
entfernten Gerat, das weitere entfernte Gerat 
anweisend zum Senden eines Kennworts zu 
dem Benutzer; Empfangsmittel zum Empfan- 
gen eines von dem Kennwort abgeleiteten 
Hash-Werts von dem weiteren entfernten Gerat 
und zum Empfangen eines weiteren Hash- 
Werts von dem Benutzer; Vergleichsmittel zum 
Vergleichen des weiteren Hash-Werts von dem 
Benutzer mit dem Hash-Wertvon dem weiteren 
entfernten Gerat; und Zertifizierungsmittel 
(1 1 0, 1 1 1 ) zum Zertifizieren der zu zertifizieren- 
den Daten, wenn der weitere Hash-Wert von 
den Benutzerdatenmitdem Hash-Wertvon dem 
weiteren entfernten Gerat korrespondiert. 

34. Datenzertifizierungsvorrichtung nach Anspruch 33, 
umfassend Mittel zum Authentifizieren einer Verbin- 
dung zwischen dem Quellengerat und der Zertifizie- 
rungsvorrichtung unter Verwendung eines festen 
Kennworts, das von der Zertifizierungsvorrichtung 
erkanntwird; und Mittel zum Herstellen eines siche- 
ren Kanals zwischen dem Quellengerat und derZer- 
tifizierungsvorrichtung unter Verwendung eines sol- 
chen Hash-Werts, empfangen von der Zertifizie- 
rungsvorrichtung, zusammen mit einem offentlichen 
Schlussel der Zertifizierungsvorrichtung zur Gene- 
rierung eines Sitzungsschliissels fur den sicheren 
Kanal. 

35. Datenzertifizierungsvorrichtung nach Anspruch 33 
oder 34, weiter umfassend Mittel zum Herstellen ei- 
nes verschlusselten Kanals zwischen dem entfern- 
ten Gerat und der Zertifizierungsvorrichtung, wobei 
die Zertifizierungsvorrichtung und das entfernte Ge- 
rat gegen Eingriffe widerstandsfahige Hardware 
(111,121) enthalten und wobei der verschlusselte 
Kanal einen sicheren Tunnel (150) zwischen dem 
entfernten Gerat und der Zertifizierungsvorrichtung 
umfasst, so dass fur den Tunnel verwendete Schlus- 
sel von der gegen Eingriffe widerstandsfahigen 
Hardware kontrol I iert werden und nichtunverschlus- 
selt auBerhalb der Zertifizierungsvorrichtung er- 
scheinen. 

36. Datenzertifizierungsvorrichtung nach Anspruch 33, 
wobei die Zertifizierungsvorrichtung Mittel zum Her- 
stellen einer authentifizierten Verbindung mit dem 
Quellengerat vor und wahrend der Ubertragung der 
zu zertifizieren den Daten umfasst 

37. Datenzertifizierungsvorrichtung nach Anspruch 36, 
wobei die authentifizierte Verbindung verschlusselt 
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wird. 

38. Datenzertifizierungsvorrichtung nach Anspruch 36 
oder 37, wobei die Zertifizierungsvorrichtung Mittel 
zum Annehmen eines Tokens von dem Quellengerat 
zur Authentifizierung umfasst und wobei die Zertifi- 
zierungsvorrichtung Mittel zur Verwendung von 
mehr als einem Typ von Token zur Authentifizierung 
des Benutzers oder Quellengerats umfasst. 

39. Datenzertifizierungsvorrichtung nach Anspruch 38, 
wobei die Datenzertifizierungsvorrichtung angeord- 
net ist zum Arbeiten durch Authentifizierung des Be- 
nutzers unabhangig von dem Quellengerat, um eine 
erste Sicherheitsstufe bereitzustellen, und zum Ar- 
beiten durch Authentifizierung des Benutzers und 
des entfernten Gerats, um eine zweite Sicherheits- 
stufe, die hoher ist als die erste Sicherheitsstufe, be- 
reitzustellen. 

40. Datenzertifizierungsvorrichtung nach Anspruch 36 
oder 37, wobei das Quellengerat Mittel umfasst zur 
Lieferung eines Tokens (1 90) an die Zertifizierungs- 
vorrichtung zur Authentifizierung und wobei die Zer- 
tifizierungsvorrichtung Mittel umfasst zur Zertifizie- 
rung der Daten mit verschiedenen eindeutigen Ele- 
menten, abhangigvondemTyp des Tokens, der zur 
Authentifizierung des Benutzers oderQuellengerats 
verwendet wird. 

41. Datenzertifizierungsvorrichtung nach einem der An- 
spruch e 33 bis 40, wobei die Zertifizierungsvorrich- 
tung einen Signaturserver (1 1 0) umfasst. 

42. Datenzertifizierungsvorrichtung nach Anspruch 41, 
wobei die Zertifizierungsvorrichtung eine Pluralitat 
von Signaturservern umfasst, jeder Signaturserver 
angeordnet ist zur Verwendung von geheimer ge- 
meinsamer Nutzung zur Speicherung von individu- 
ellen Anteilen eines privaten Schlussels eines Be- 
nutzers, in dem die Signatur generiert wird. 

43. Datenzertifizierungsvorrichtung nach Anspruch 41 
oder 42, wobei die Zertifizierungsvorrichtung weiter 
einen Authentifiziemngsserver (120) umfasst. 



Revendi cations 

1. Precede de certification de donnees electroniques 
qui sontfournies par un utilisateur, le procede com- 
prenant: 

la reception de donneesfournies par I'utilisateur 
destinees a etre certifiees au niveau d'un appa- 
reil de certification (110) depuis un dispositif de 
source (101); 

renvoi d'une requete sur un dispositif a distance 



(120) demandant en instruction au dispositif a 
distance d'envoyer un mot de passe a I'utilisa- 
teur; 

la reception d'une valeurde hachagequi est de- 
s rivee a partir du mot de passe en provenance 

du dispositif a distance; 

la reception d'une autre valeur de hachage en 
provenance de I'utilisateur; 
la comparaison de I'autre valeurde hachage en 
10 provenance de I'utilisateur avec la valeur de ha- 

chage en provenance du dispositif a distance 
afin d'ainsi valider I'utilisateur; 
la certification des donnees au niveau de I'ap- 
pareil de certification (110), moyennant un ou 
15 plusieurs elements d'information de securite 

pour I'appareil de certification, lesdits elements 
etant uniques pour I'utilisateur, si I'autre valeur 
de hachage correspond a la valeurde hachage 
qui est derivee a partir du dispositif a distance; et 
20 remission en sortie des donnees ainsi certifiees 

depuis I'appareil de certification (110) pour un 
passage sur un dispositif recepteur, 

dans lequel les elements d'information de securite 
25 certifient que le fournisseur des donnees est I'utili- 
sateur. 

2. Procede selon la revendication 1, comprenant en 
outre I'authentification d'une connexion entre ledit 
30 dispositif de source et ledit appareil de certification 
en utilisant un mot de passe fixe qui est reconnu par 
ledit appareil de certification; et I'etablissement d'un 
canal securise entre ledit dispositif de source et ledit 
appareil de certification en utilisant une dite valeur 
35 de hachage qui est recue par ledit appareil de certi- 
fication en association avec une cle publique dudit 
appareil de certification afin de generer une cle de 
session pour ledit canal securise. 

40 3. Procede selon la revendication 1 ou 2, comprenant 
en outre I'etablissement d'un canal crypte entre ledit 
dispositif a distance et ledit appareil de certification, 
dans lequel ledit appareil de certification et ledit dis- 
positif a distance indue nt un composant materiel re- 
<5 sistant a la violation (1 1 1, 121) et dans lequel ledit 
canal crypte com p rend un tunnel securise (150) en- 
tre ledit dispositif a distance et ledit appareil de cer- 
tification de telle sorte que des cles qui sont utilisees 
pour le tunnel soient commandees par ledit compo- 
st? santmateriel resistant a la violation etn'apparaissent 
pas en clair a I'exterieur dudit appareil de certifica- 
tion. 

4. Procede selon la revendication 1 , 2 ou 3, dans lequel 
55 la cle privee d'une paire cle publique/cle privee spe- 

cifique a I'utilisateur definit un dit element qui est 
unique pour I'utilisateur. 



15 



20 



25 



30 



35 



40 



45 



20 



37 



EP 1 364 508 B1 



38 



5. Procede selon Tune quelconque des revendications 
precedentes, dans lequel une signature numerique 
qui est specifique a I'utilisateur definit un dit element 
qui est unique pour I'utilisateur. 

6. Procede selon Tune quelconque des revendications 
precedentes, dans lequel le dispositif recepteur est 
le dispositif de source. 

7. Procede selon Tune quelconque des revendications 
1 a 6, dans lequel le dispositif recepteur est un dis- 
positif de tierce partie. 

8. Procede selon Tune quelconque des revendications 
precedentes, dans lequel une valeur de hachage 
d'un message a certifier est generee au niveau du 
dispositif de source, la valeur de hachage etant les 
donnees destinees a etre certifiees par I'appareil de 
certification. 

9. Procede selon Tune quelconque des revendications 
precedentes, dans lequel I'appareil de certification 
est adapte pour recevoir des donnees en provenan- 
ce d'une pluralite de differents dispositifs de source. 

10. Procede de certification de donnees electroniques 
qui sontfournies par un utilisateur, le procede com- 
prenant: 

I'etablissement d'une connexion securisee en- 
tre un dispositif de source (101) qui est actionne 
par I'utilisateur et un appareil de certification 
(110); 

I'envoi de donnees qui sont fournies par I'utili- 
sateur depuis le dispositif de source (101) pour 
qu'elles soient recues par I'appareil de certifica- 
tion (110); 

la reception d'un mot de passe en provenance 
d'un dispositif a distance; 
I'envoi d'une valeur de hachage dudit mot de 
passe sur I edit appareil de certification; et 
la reception, au niveau du dispositif de source, 
d'une version des donnees en provenance de 
I'appareil de certification (1 1 0) qui sont certifiees 
commeemanantde I'utilisateur, en utilisantune 
information qui est unique pour I'utilisateur. 

11. Procede selon la revendication 10, comprenant en 
outre I'authentification d'une connexion entre ledit 
dispositif de source et ledit appareil de certification 
en utilisant un mot de passe fixe qui est reconnu par 
ledit appareil de certification; et I'etablissement d'un 
canal securise entre ledit dispositif de source et ledit 
appareil de certification en utilisant ladite valeur de 
hachage en association avec une cle publique dudit 
appareil de certification afin de generer une cle de 
session pour ledit canal securise. 



12. Procede selon la revendication 10 ou 11, compre- 
nant en outre I'etape d'incorporation d'une version 
certifiee des donnees dans d'autres donnees desti- 
nees a etre envoyees par un dispositif de tierce par- 

s tie. 

13. Procede selon la revendication 10, 11 ou 12, dans 
lequel I'appareil de certification contient une infor- 
mation qui est unique pour que I'utilisateur mette en 

10 oeuvre la certification. 

14. Procede selon la revendication 13, dans lequel Pin- 
formation unique est la cle privee d'une paire cle 
publique/cle privee specifique a I'utilisateur. 

15 

15. Procede selon la revendication 13 ou 14, dans lequel 
I'information unique est une signature numerique 
specifique a I'utilisateur. 

20 16. Procede selon Tune quelconque des revendications 
1 0 a 1 5, dans lequel les donnees a certifier sont une 
valeur de hachage d'un message. 

17. Procede selon Tune quelconque des revendications 
25 precedentes, dans lequel I'appareil de certification 

comprend un serveur de signature (1 1 0). 

18. Procede selon Tune quelconque des revendications 
precedentes, dans lequel I'appareil de certification 

30 comprend une pluralite de serveurs de signature qui 
utilisent un partage de secret pour stocker des par- 
ties individuelles d'une cle privee d'un utilisateur et 
dans lequel la signature est generee sur la base de 
parties individuelles d'une cle privee d'un utilisateur 

35 qui est stockee sur certains ou tous des serveurs de 
signature. 

19. Procede selon la revendication 17ou 18, dans lequel 
I'appareil de certification comprend en outre un ou 

40 plusieurs serveurs d'authentification (120). 

20. Procede selon I'une quelconque des revendications 
precedentes, dans lequel le dispositif de source 
(101) comprend une station de travail. 

45 

21. Procede selon la revendication 20, comprenant en 
outre I'etablissement d'un canal de communication 
verifie et authentifie independant entre la station de 
travail et le dispositif a distance. 

50 

22. Procede selon I'une quelconque des revendications 
1 a 1 9, dans lequel le dispositif de source comprend 
une television interactive. 

55 23. Procede selon I'une quelconque des revendications 
precedentes, dans lequel le dispositif de source et 
I'appareil de certification etablissent des connexions 
individuelles authentifiees entre le dispositif de sour- 



21 



39 



EP 1 364 508 B1 



40 



ce et un ou plusieurs serveurs de I'appareil de cer- 
tification avant et pendant un transfert des donnees 
a certifier. 

24. Precede selon la revendication 23, dans lequel le 
procede fonctionne en authentifiant I'utilisateur in- 
dependamment du dispositlf de source afin d'assu- 
rer un premier niveau de securite et fonctionne en 
a uth entif i ant I' uti li sat e u r et I e d ispos itif de so u rce af i n 
d'assurer un second niveau de securite qui est su- 
perieur au premier niveau de securite. 

25. Procede selon les revendi cations 1 ou 10, dans le- 
quel le dispositif de source applique un jeton (190) 
sur I'appareil de certification pour une authentica- 
tion et dans lequel I'appareil de certification certifie 
les donnees avec differents elements uniques en 
fonction du type de jeton qui est utilise pour authen- 
tifier I'utilisateur ou le dispositif de source. 

26. Procede selon Tune quelconque des revendications 
precedentes, dans lequel des donnees de validation 
pour valider les donnees a certifier sont recues de- 
puis un dispositif a distance avant que les donnees 
ne soient certifiees. 

27. Procede selon I'une quelconque des revendications 
precedentes, comprenant en outre le fait que I'ap- 
pareil de certification envoie la requete sur le dispo- 
sitif a distance apres reception d'une requete pour 
certifier des donnees. 

28. Procede selon I'une quelconque des revendications 
1 a 27, comprenant en outre: 

la reception d'une requete en provenance dudit 
appareil de certification au niveau dudit dispo- 
sitif a distance pour fournir a I'utilisateur ledit mot 
de passe; 

lafourniture dudit mot de passe a I'utilisateur; et 
lafourniture de ladite valeur de hachage qui est 
derivee a parti r dudit mot de passe a I'appareil 
de certification. 

29. Procede selon I'une quelconque des revendications 
precedentes, dans lequel ledit mot de passe est un 
mot de passe "une fois". 

30. Procede selon la revendication 28 ou 29, dans lequel 
la requete et ladite valeur de hachage qui est derivee 
a partir dudit mot de passe sont transferees via un 
procede de communication different audit mot de 
passe. 

31. Support d'infomnation lisible parordinateurqui stoc- 
ke des instructions qui, lorsqu'elles sont executees 
par un ordinateur, ont pour effet que I'ordinateur rea- 
lise chacune des etapes de procede selon I'une quel- 



conque des revendications 1 a 9. 

32. Support d'information lisible parordinateurqui stoc- 
ke des instructions qui, lorsqu'elles sont executees 

s par un ordinateur, ont pour effet que I'ordinateur rea- 
lise chacune des etapes de procede selon I'une quel- 
conque des revendications 10 a 30. 

33. Appareil de certification de donnees (11 0, 1 20) com- 
10 prenant: 

un dispositif de signature (110, 111) qui est 
adapte pour certifier des donnees electroniques 
qui sont recues depuis un dispositif de source a 
15 distance (1 01 ) en tant que donnees prenant leur 

origine aupres d'un utilisateur, dans lequel I'ap- 
pareil de certification est agence pour recevoir 
des donnees en provenance du dispositif de 
source, pour certifier les donnees en tant que 
20 donnees appartenant a I'utilisateur, en utilisant 

une information qui est stockee dans I'appareil 
de certification ainsi que des techniques crypto- 
graphiques, ladite information etant unique pour 
I'utilisateur, et pour envoyer les donnees certi- 
25 fiees a un dispositif recepteur; et comprenant en 

outre un moyen destruction pour envoyer une 
requete a un autre dispositif a distance deman- 
dant en instruction que I 'autre dispositif a dis- 
tance envoie un mot de passe a I'utilisateur; un 
30 moyen de reception pour recevoir une valeur de 

hachage qui est derivee a partir du mot de passe 
en provenance de I'autre dispositif a distance et 
pour recevoir une autre valeur de hachage en 
provenance de I'utilisateur; un moyen de com- 
35 paraisonpourcomparer I'autre valeurde hacha- 

ge en provenance de I'utilisateur avec la valeur 
de hachage en provenance de I'autre dispositif 
a distance; et un moyen de certification (110, 
1 1 1) pour certifier les donnees destinees a etre 
40 certifiees si I'autre valeur de hachage en prove- 

nance de I'utilisateur correspond a la valeur de 
hachage en provenance de I'autre dispositif a 
distance. 

<5 34. Appareil de certification de donnees selon la reven- 
dication 33, comprenant un moyen pour authentifier 
une connexion entre ledit dispositif de source et ledit 
appareil de certification en utilisant un mot de passe 
fixe qui est reconnu par ledit appareil de certification; 
50 et un moyen pour etablir un canal sec u rise entre ledit 
dispositif de source et ledit appareil de certification 
en utilisant une dite valeur de hachage qui est recue 
par ledit appareil de certification en association avec 
une cle publique dudit appareil de certification afin 
55 de generer une cle de session pour ledit canal se- 
curise. 

35. Appareil de certification de donnees selon la reven- 
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dication 33 ou 34, comprenant en outre un moyen 
pour etablir un canal crypte" entre ledit dispositif a 
distance et ledit appareil de certification, dans lequel 
ledit appareil de certification et ledit dispositif a dis- 
tance incluent un composant materiel resistant a la 
violation (111, 1 21 ) et dans lequel ledit canal crypte 
comprend un tunnel securise (150) entre ledit dis- 
positif a distance et ledit appareil de certification de 
telle sorte que des cles qui sont utilisees pour le tun- 
nel soient commandees au moyen dudit composant 
materiel resistant a la violation et n'apparaissent pas 
en clair a I'exterieur dudit appareil de certification. 

36. Appareil de certification de donnees selon la reven- 
dication 33, dans lequel I'appareil de certification 
comprend un moyen pour etablir une connexion 
authentifiee avec le dispositif de source avant et pen- 
dant un transfert de donnees a certifier. 

37. Appareil de certification de donnees selon la reven- 
dication 36, dans lequel ladite connexion authenti- 
fiee est crypte e. 

38. Appareil de certification de donnees selon la reven- 
dication 36 ou 37, dans lequel I'appareil de certifica- 
tion comprend un moyen pour accepter un jeton en 
provenance du dispositif de source pour une authen- 
tication et dans lequel I'appareil de certification 
comprend un moyen pour utiliser plus d'un type de 
jeton pour authentifier I'utilisateur ou le dispositif de 
source. 

39. Appareil de certification de donnees selon la reve in- 
dication 38, dans lequel I'appareil de certification de 
donnees est agence pour fonctionner en authenti- 
fiant I'utilisateur independamment du dispositif de 
source afin d' assurer un premier niveau de securite 
et pour fonctionner en authentifiant I'utilisateur et le 
dispositif de source afin d'assurer un second niveau 
de securite qui est superieur au premier niveau de 
securite. 

40. Appareil de certification de donnees selon la reven- 
dication 36 ou 37, dans lequel le dispositif de source 
comprend un moyen pourfournir un jeton (190) a 
I'appareil de certification pour authentication et 
dans lequel I'appareil de certification comprend un 
moyen pour certifier les donnees moyennant des 
elements uniques differents en fonction du type de 
jeton qui est utilise pour authentifier I'utilisateur ou 
le dispositif de source. 

41 . Appareil de certification de donnees selon I'une quel- 
conquedes revendications 33 a 40, dans lequel I'ap- 
pareil de certification comprend unserveurde signa- 
ture (110). 

42. Appareil de certification de donnees selon la reven- 



dication 41, dans lequel I'appareil de certification 
comprend une pluralite de serveurs de signature, 
chaque serveur de signature etant agence pour uti- 
liser un partage de secret afin de stocker des parties 
s individuelles d'une cle privee d'un utilisateur, ou la 
signature est generee. 

43. Appareil de certification de donnees selon la reven- 
dication 41 ou 42, dans lequel I'appareil de certifica- 
te tion comprend en outre un serveur d'authentification 
(120). 
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